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Abstract 


This  report  examines  some  of  the  issues  that  arise  when  the  State  Delta  Verification  System 
(SDVS)  is  used  for  the  analysis  of  code  fragments  extracted  from  larger  bodies  of  “produc¬ 
tion”  code.  The  code  fragment  must  be  isolated  from  the  larger  body  of  code  -  by  narrowing 
its  interface  to  other  program  components.  It  must  often  be  altered  as  well,  to  satisfy  the 
narrowed  interface  semantics  or  to  match  available  SDVS  capabilities.  These  issues  are 
illustrated  by  means  of  a  running  example,  involving  a  heapsort  written  in  Ada.  The  code 
is  prepared  for  SDVS  analysis,  with  the  intention  of  proving  that  index-out-of-range  condi¬ 
tions  cannot  arise  during  execution.  A  bug  is  uncovered  in  the  original  source  code  in  the 
course  of  the  analysis  and  the  bug  is  fixed.  The  planned  proof  is  then  sucessfuUy  carried  out 
for  the  corrected  heapsort  code.  The  point  of  view  is  that  of  a  relatively  unsophisticated 
user  of  the  SDVS  system. 
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1  Introduction 


This  report  examines  some  of  the  issues  that  arise  in  applying  the  State  Delta  Verification 
System  (SDVS)  to  fragments  of  code  extracted  from  a  larger  “production”  code.  The 
intended  use  of  SDVS  in  such  a  case  is  the  analysis  of  the  code  fragment  by  verification  of 
selected  properties.  The  properties  selected  for  analysis  are  determined  by  the  purpose  for 
which  the  analysis  is  undertaken. 

In  this  report,  it  is  taken  for  granted  that  the  reader  is  familiar  with  both  the  Ada  language 
[1]  and  SDVS  [2,  3]. 

In  order  to  make  SDVS  analysis  a  practical  proposition,  a  code  fragment  of  interest  must  be 
isolated  from  the  larger  matrix  of  the  production  program  that  contains  it.  This  can  be  a 
daunting  task  because  of  dependencies  in  the  code.  Typically,  the  fragment  one  wants  must 
be  extracted  along  with  a  procedure  in  which  it  is  nested.  (Of  course,  other  types  of  com¬ 
pilation  units  may  be  involved.)  The  procedure  may  use  data  types,  constants,  functions, 
and  procedures  that  are  defined  in  packages  identified  in  with-clause(s)  of  the  enclosing 
program.  Some  minimal  set  of  definitions,  sufficient  to  exercise  the  code  fragment,  must 
be  singled  out.  Actually,  the  set  need  not  be  strictly  minimal,  but  it  must  be  of  practical 
proportions.  Simply  including  everything  in  the  contents  of  every  package  mentioned  in  a 
with-clause  into  the  set  of  definitions  needed  will  (given  almost  any  design  for  a  production 
code  of  even  moderate  size)  produce  too  large  a  body  of  code  for  practical  use  in  SDVS.  The 
selection  of  an  appropriate  set  of  definitions  to  exercise  the  code  fragment  is  what  is  here 
termed  “narrowing  the  interface”  (between  the  code  fragment  and  the  rest  of  the  code). 

The  need  to  narrow  the  interface  is  primarily  due  to  the  fact  that  the  current  version  of 
the  SDVS  system  is  designed  to  analyze  entire  Ada  programs.  While  it  has  facilities  to 
deal  with  subprograms  (for  instance,  the  adalemma  capability  for  proving  assertions  about 
subprograms  [4,  5]),  it  requires  an  entire  program  for  context.  Thus  the  code  fragment 
plus  the  selected  set  of  definitions  on  which  it  depends  must  be  encapsulated  in  an  Ada 
program.  Of  course,  the  appropriate  context  for  a  program  fragment  must  be  supplied 
somehow,  and  it  is  usually  not  completely  local  to  the  fragment;  this  is  thus  an  issue  faced 
by  any  verification  system,  and  requiring  a  complete  program  is  probably  the  best  interim 
solution.  In  principle,  one  can  input  a  large  program  to  the  SDVS  Ada  translator  and 
subsequently  restrict  one’s  attention  to  the  area  of  the  code  fragment  of  interest.  This 
can  be  done  by  selecting  local  properties,  involving  the  code  fragment,  for  verification.  In 
practice,  however,  inputting  a  large  program  will  substantially  increase  the  likelihood  of 
running  into  some  Ada  language  feature  that  is  not  within  the  capabilities  of  the  current 
version  of  SDVS.  For  instance,  at  the  time  this  report  was  written,  SDVS  did  not  handle 
floating  point  arithmetic,  even  though  that  is  clearly  likely  to  show  up  in  production  code 
(see  [6]  for  future  plans).  Once  the  code  fragment  has  been  encapsulated  in  a  “scaffold” 
Ada  program,  it  can  be  considered  isolated  from  its  matrix. 

Now  consider  source  code  transformations  that  may  have  to  be  applied  to  the  fragment.  If 
one  wants  to  claim  that  one  has  verified  (some  property  of)  a  code  fragment  extracted  from 
a  production  program,  it  is  obviously  desirable  to  have  analyzed  an  isolated  fragment  in 
SDVS  that  is  syntactically  identical  to  the  original  fragment.  Even  when  that  is  the  case, 
one  must  (informally,  at  least)  show  that  the  semantics  of  the  isolated  fragment  and  the 
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original  fragment  either  agree,  or  are  related  in  a  way  that  does  not  violate  the  assumptions 
of  the  analysis.  (Two  syntactically  identical  pieces  of  code  may  well  have  entirely  diiferent 
semantics  when  encapsulated  in  dilferent  matrices;  for  instance,  two  procedures  with  the 
same  name  in  the  fragment  may  be  defined  differently.)  Unfortunately,  the  ideal  of  syntactic 
identity  is  rarely  achievable.  Changes  to  the  source  of  the  original  fragment  may  be  required 
to  deal  with  differences  in  the  textual  context  (the  selected  scaffolding  and  the  original 
production  program).  However,  this  is  not  the  main  reason  why  source  code  changes  are 
required.  Rather,  that  reason  is  the  limited  Ada  language  capabilities  of  the  current  version 
of  SDVS.  Constructs  that  the  translator  cannot  handle  must  be  replaced  by  equivalent  (for 
analysis  purposes)  ones  that  can  be  handled.  The  term  “transformation”  in  the  title  of  this 
document  refers  to  any  syntactic  changes  to  the  original  program  fragment. 

In  so  far  as  the  analysis  purports  to  apply  to  the  original  fragment,  informal  proofs  must 
be  supplied  to  show  that  the  transformations  applied  to  the  source  code  either  have  no 
effect  on  the  semantics  of  the  program,  or  at  least  do  not  violate  the  assumptions  of  the 
analysis.  The  topics  discussed  in  general  terms  in  the  preceding  paragraphs  are  illustrated  in 
concrete  form  in  the  remainder  of  this  report.  This  is  done  by  means  of  a  running  example, 
in  which  an  Ada  heapsort  is  isolated  and  transformed,  and  then  is  subjected  to  analysis 
using  SDVS.  The  heapsort  procedure  is  the  code  fragment  to  be  analyzed.  The  procedure 
was  written  by  Dr.  Rami  Razouk,  of  Aerospace,  in  support  of  the  Defense  Support  Program 
(DSP)  program  office.  It  was  consciously  written  as  a  line-for-line  translation  of  a  Fortran 
program.  It  represents  an  approximation  to  code  that  the  contractor  plans  to  deliver  later, 
and  was  originally  embedded  in  the  contractor’s  prototype  Ada  software.  The  purpose  that 
Dr.  Razouk  had  in  mind,  in  translating  the  Fortran  code,  was  to  use  it  to  demonstrate 
some  properties  of  the  sort  procedure  related  to  speed  of  execution,  under  different  sets  of 
conditions  involving  the  use  of  different  compilers  and  different  compiler  options.  SDVS 
entered  the  picture  because  one  of  the  compiler  options  investigated  was  index  checking 
for  arrays,  and  Dr.  Razouk  was  interested  in  the  question  of  whether  one  could  prove  that 
index  checking  could  be  turned  off  (using  pragma  suppress)  with  the  assurance  that  there 
would  be  no  (unnoticed)  out-of-range  conditions. 

To  answer  this  question,  one  must  verify  the  property  that  the  variables  used  as  indices  for 
the  array  in  question  are  always  in  bounds.  This  turns  out  to  be  eminently  amenable  to 
SDVS  analysis,  because  SDVS  checks  that  array  indices  are  within  bounds  during  symbolic 
execution.  In  detail,  before  each  reference  to  an  array  element,  SDVS  requires  the  verifica¬ 
tion  of  the  inequalities  needed  to  establish  that  variables  or  expressions  used  as  indices  are 
within  bounds.  A  program  for  which  SDVS  can  prove  termination  therefore  cannot  corrupt 
memory  by  means  of  its  array  assignment  statements,  and  this  answers  the  principal  con¬ 
cern  involved  in  the  use  of  index  checking.  Interestingly  enough,  the  SDVS  analysis  turned 
up  a  bug  that  could  be  traced  directly  back  to  the  Fortran  original. 

The  point  of  view  of  this  report  is  that  of  a  naive  user.  This  report  springs  from  a  dual  effort 
to  train  a  new  SDVS  user  (the  author)  and  to  institute  a  search  for  production  code  (defined 
as  program  specific  code,  either  prototype  or  deliverable)  suitable  for  SDVS  analysis. 
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2  Original  Source  Code 


The  code  fragment  that  will  be  used  as  the  basis  for  the  running  example  in  this  document 
is  a  heapsort.  It  was  extracted  from  a  prototype  version  of  a  DSP  contract  deliverable.  It 
should  be  noted  that  (1)  the  code  was  not  a  final  version;  (2)  it  was  not  therefore,  in  any 
sense,  a  contract  deliverable;  (3)  the  actual  heapsort  procedure  was,  in  fact,  not  written 
by  the  contractor;  and  (4)  the  code  is  a  direct  translation  into  Ada  of  a  Fortran  heapsort. 
However,  the  code  (5)  was  created  for  program  specific  analysis  purposes;  (6)  was  part 
of  a  larger  system  prototype;  and  (7)  was  tested  repeatedly  in  the  context  of  the  system 
prototype. 

In  the  system  context,  the  purpose  of  the  heapsort  routine  was  to  sort  an  array  of  radar 
return  records  by  ascending  value  of  one  specific  floating-point  component.  To  accomplish 
this,  the  procedure  was  passed  input  parameters  consisting  of  an  index  bound  (N)  and  the 
array  of  floating-point  values  (X).  The  values  to  be  sorted  were  thus  defined  as  the  values 
X(l),  X(2),  . . .  ,  X(N).  These  parameters  were  not  to  be  changed;  in  particular,  the  order 
of  values  in  the  array  could  not  be  changed.  Instead,  the  sort  procedure  was  to  operate  by 
returning  a  permutation  of  the  original  index  values  1,  . . .  ,  N,  namely  an  array  (lOUT), 
with  the  property  that  the  sequence  X(I0UT(1)),  . . .  ,  X(IOUT(N))  is  in  ascending  order. 
Figure  1  shows  the  Ada  specification  for  the  package  (HEAPSRT_PACK)  containing  the 
heapsort  procedure  (HEAPSRT),  just  as  it  appeared  (except  for  minor  name  changes)  in 
the  system  prototype. 

Bith  ATirPES_PACK;  use  ATYPES.PACK; 

package  HEAPSRT.PACK  is 

procedure  BEAPSRT  (I  :  in  RR.RAIGE; 

I  :  in  I_RR.ARRAY  ;  — 
lOUT  :  in  ont  RR.IBDEX.ARRAY) ; 

end  1EAPSRT_PACK; 


Figure  1:  Specification  for  the  HEAPSRT  Package 

Without  a  look  at  ATYPES_PACK,  the  above  is  not  very  informative.  The  package 
ATYPE_PACK  defines  the  type  RR_RANGE  as  a  subtype  of  integer,  X_RR_ARRAY  as  an 
array  type  with  index  type  RR_RANGE  and  value  type  REALS,  and  RRJNDEX_ARRAY 
as  an  array  type  with  index  type  RR_RANGE  and  value  type  RR_RANGE.  The  type  REALS 
is  a  floating-point  type,  so  it  is  floating-point  values  that  the  routine  sorts.  Refer  to  Figure 
2,  the  body  of  the  procedure,  and  note  that  all  the  variables  used  in  index  calculations  are 
of  type  RR_RANGE,  and  that  the  single  variable,  Q,  used  in  value  comparisons  is  of  type 
REALS  (and  is  compared  to  array  values  and  assigned  the  value  of  array  entries).  In  the 
next  section  the  isolation  of  the  procedure  and  its  encapsulation  in  a  stand-alone  scaffold 
program  will  be  addressed. 
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Bith  ATYPES_PACK;  nee  ATYPES.PACK; 

package  body  EEAPSET.PACK  is 

procednze  BEAPSRT  (1  ;  in  RR.KAIGE;  — 

X  :  in  X_IIR_AIIRAY  ;  — 
lOUT  :  in  ont  RR.IIDEZ.ARRAT)  is 
I.L.IR,J,IOUTT:  RR_RAIGE;  Q:  REALS; 
begin 

for  K  in  1 . .1  loop 
I0UT(K):=X; 
end  loop;  — for  K 
L:=RR.RAIGE(IITEGER(I)/2-)-l) ; 

IR:=I; 

«L10»nnll; 

if  L>1  then 
L:=L-1; 

IOUTT:=IOUTa); 

q:=X(I0UTT); 

else 

I0UTT:=I0UT(IR); 

Q;=X(IOUTr); 

I0UT(IR):=I0UT(1); 

IR:=IR-1; 
if  IR=1  then 

IOUT(l):=IOUTr; 
goto  LEID; 
end  if; 
end  if; 

I:=L: 

J:=L+L; 

«L20»nnll; 

if  J<=IR  then 
if  J<IR  then 

if  X(I0UT(J))<X(I00T(J+1))  then 
J:=J+1; 
end  if; 
end  if; 

if  Q<X(I0UT(J))  then 
IOUTa):=IOUT(J); 

I:=J; 

J:=J+J; 

else 

J:=IR+1; 
end  if; 
goto  L20; 
end  if; 

lOUT(I) :=I0UTT; 
goto  LIO; 

«LEHD»nnll; 
end  HEAPSRT; 
end  HEAPSRT_PACK; 


Figure  2:  Body  for  the  HEAPSRT  Package 
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3  SDVS  Version  of  the  Code 


The  fragment  of  interest  is  the  HEAPSRT  procedure,  so  the  package  HEAPSRT_PACK 
can  he  ignored.  To  create  a  scaffold  program  for  procedure  HEAPSRT,  a  substitute  for 
ATYPES  JPACK  is  required.  In  addition,  it  will  be  desirable  to  have  a  main  program  that 
exercises  HEAPSRT  at  least  minimally.  This  is  not  strictly  necessary,  as  the  ultimate 
objective  is  to  establish  desired  properties  of  the  procedure  solely  by  proof. 

The  original,  production  version  ATYPES_PACK  can  be  stripped  of  additional  items  to 
the  point  where  it  contains  only  the  definitions  truly  needed  for  HEAPSRT,  namely  those 
of  RR_RANGE,  X_RR_ARRAY,  RRJNDEX_ARRAY,  and  REALS.  These  are  all  defined 
directly  in  terms  of  Ada  basics.  However,  they  involve  two  constructs  that  the  current 
version  of  SDVS  is  not  prepared  to  handle:  subtypes  (of  integer)  and  floating  point  types. 
(This  is  expected  to  change  soon,  with  the  likely  introduction  of  subtypes  in  1993  and  the 
introduction  of  floating  point  under  study  [6]). 

To  avoid  floating  point  types,  the  value  types  of  the  arrays  will  have  to  be  something  else, 
and  the  integer  type  is  a  sensible  choice.  At  this  point  one  must  invoke  the  first  informal 
argument.  Claim:  for  the  purposes  of  the  analysis  (verifying  that  index  constraints  are  not 
violated  during  assignment),  it  does  not  matter  what  the  value  type  of  the  array  is,  as  long 
as  it  is  ordered.  Not  even  an  informal  proof  of  this  claim  will  be  attempted.  Indeed,  none 
should  be  necessary,  as  the  claim  is  fairly  obvious.  The  purpose  of  these  remarks,  though, 
is  to  make  that  claim  explicit,  and  to  observe  that  (1)  it  is  necessary  to  make  the  claim  to 
support  the  analysis,  and  (2)  the  claim  is  not  being  formally  verified. 

Currently,  SDVS  handles  arrays  whose  indices  are  integers  within  a  range  of  the  form  i..j, 
where  i  and  j  are  themselves  integers.  It  does  not  handle  the  direct  declaration  of  ranges 
(e.g.  Nor  does  it  allow  for  the  declaration  of  subtypes  of  integer,  or  of  derived  integer 
types.  The  only  practical  remaining  possibility  is  to  declare  aU  the  array  types  involved 
to  have  syntactically  identical  (anonymous)  index  types  that  are  implicit  integer  subtypes 
of  the  range  {i-.j)  type.  As  the  original  code  assumes  a  lower  bound  of  1,  the  appropri¬ 
ate  definition  is  that  of  a  global  upper  bound  for  aU  indices,  MAX_RR.  In  those  terms, 
X_RR_ARRAY  becomes  an  array  with  index  type  l..MAX_RR  and  value  type  integer,  and 
RRJNDEX-ARRAY  becomes  an  array  type  with  index  type  l..MAXJR,R  and  value  type  in¬ 
teger.  Ideally,  the  value  type  of  RRJNDEX_ARRAY  would  be  constrained  to  l..MAXJR,R, 
but  this  constraint  cannot  be  expressed  without  the  ability  to  designate  the  index  type 
l..MAX_RR  directly.  The  use  of  a  formally  (syntactically)  different  form  of  declaration  for 
the  array  types  that  appear  in  procedure  HEAPSRT  once  again  makes  an  implicit  appeal 
to  a  claim  that  the  analysis  is  not  affected  by  this  change.  Here  the  nature  of  the  claim  is 
that  of  the  semantic  equivalence  of  differing  Ada  declarations.  In  fact,  the  Ada  reference 
manual  [1,  3.6.1]  supports  the  claim  that  two  different  array  declarations  of  the  form  type  . . . 
is  array(i..j)  of .. .  implicitly  define  anonymous,  compatible  integer  subtypes  as  the  index 
type  for  the  arrays  or  array  types. 

Figure  3  shows  the  scaffolding  code  built  to  support  analysis  of  the  HEAPSRT  procedure. 
The  array  type  definitions  have  been  encapsulated  in  a  package  ATYPES  JPACK,  to  make  it 
as  similar  to  the  original  as  possible,  and  that  package  is  declared  directly  in  the  outer  scope 
of  the  main  program.  In  the  original  version  of  ATYPES_PACK  there  was  a  definition  of  the 
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Bith  tert.io;  use  tezt.io; 
with  integer.io;  nse  integer.io; 
procedure  sdvs_heapsrt  is 

— - - packaged  type  declarations 

package  ATYPES.PACK  is 

HAX_RR  :  constant  integer  ;=  22; 
type  X_&R_ARKAy  is  array(l..l(AZ_BR)  of  integer; 
type  RR_IIDEZ_AKRAy  is  arrayCl. .IUZ_EE)  of  integer; 
end  ATyPES_PACK; 
use  ATYPES.PACK; 

- - - - data  declarations 

1  :  integer; 

Z  :  Z_Ra_ARRAy; 

Z  :  aA_IIDEZ_Amy; 

— — - heapsort  procedure 

{See  Figure  4  for  the  proceiure  body} 

- — - begin  main  procedure 

begin  --  sdvs.heapsrt 


Z(l) 

=  1; 

Z(2} 

=  -16; 

Z(3) 

=  4; 

Z(4) 

=  3S67 

Z(5) 

=  -42; 

Z(6) 

=  0; 

Z  :=  1; 

Bbile  K  <=  6  loop 
put(Z(K)); 

K  :=  K+1; 
end  loop; 

K  :=  6; 

HEAPSRT(K.Z,Z); 

K  :=  1; 

Bbile  K  <s  G  loop 
put<Z<Z(K))); 

K  :=  K  +  1; 
end  loop; 
end  sdvs_beapsrt ; 


Figure  3:  Scaffolding  Code  for  SDVS  Version 


type  REALS  as  weU.  This  cannot  be  done  for  the  SDVS  scaffold  version,  because  REALS 
is  to  be  replaced  by  a  basic  type  (integer),  and  there  is  currently  no  aliasing  possibility  in 
SDVS  (one  cannot  define  REALS  to  be  a  subtype  or  derived  type  of  the  integer  type). 

The  scaffold  code  contains  a  number  of  executable  statements,  including  assignments  to 
define  array  values,  a  call  to  the  procedure  HEAPSRT,  and  I/O  statements  to  print  out  the 
sorted  values.  Clearly,  a  trivial  test  of  the  operation  of  the  procedure  HEAPSRT,  such  as 
that  coded  into  the  scaffold,  does  nothing  to  prove  properties  of  the  procedure  in  general. 
In  principle,  one  could  use  scaflFold  code  that  never  calls  the  procedure  of  interest  and  stiU 
verify  properties  of  the  procedure.  In  fact,  in  the  application  of  SDVS  to  the  analysis  of 
the  procedure  HEAPSRT,  the  heart  of  the  analysis  lies  in  the  proof  of  a  lemma  establishing 
that  the  output  array  lOUT  is  indeed  an  array  of  indices,  and  the  executable  statements  in 
the  outer  scope  are  of  virtually  no  interest.  But  in  practice,  to  guard  against  gross  errors 
(e.g.  typos  and  omissions),  the  entire  program  (scaffold  and  fragment)  should  be  tested  by 
compiling  it  using  a  reliable  Ada  compiler  and  running  the  resulting  executable,  before  any 
attempt  at  SDVS  analysis. 
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procedure  HEAPSRT  (I  :  in  integer; 

X  :  in  I_IlR_AmY  ; 
lOUT  :  in  ont  RR.IIDEI_A1ULAY)  is 

I,L,IR,J,IOUTT:  integer;  Q:  integer; 

K, LABEL:  integer; 

Begin 

K  :=  1; 

while  K  <=  I  loop 
IOnT(K):=I; 

X  ;=  K  +  1; 
end  loop; 

L: =1/2+1; 

IE:=I; 

LABEL  :=  10; 
while  LABEL  /=  30  loop 
if  LABEL  =  10  then 
if  L>1  then 
L;=L-1; 

I0UTT:=I0UT(L); 

q;=I(I0UTT); 

else 

I0trrT:=I0UTaB); 
q:=X(I0UTT); 
lOUTCIR) :=IQnT<l) ; 

IR:=IR-1; 
if  IR=1  then 

I0OT(1):=I0UTT; 

LABEL  :=  30; 
end  if; 
end  if; 

if  LABEL  /=  30  then 
I:=L; 

J:=L+L; 

LABEL  :=  20; 
end  if; 

els if  LABEL  =  20  then 
if  J<=IR  then 
if  J<IR  then 

if  X(IOUT(J))<X(IOOT{J+1))  then 
J:=J+1; 
end  if; 
end  if; 

if  q<X(IOOT(J))  then 
I0HT(I):=I0UT(J); 

I:=J; 

J:=J+J; 

else 

J:=IB+1; 
end  if; 

else 

I0HT(I):=I0DTT; 

LABEL  :=  10; 
end  if; 

end  if;  —  “case"  statement  on  LABEL  valnes 
end  loop;  --  while  LABEL  /=  30 
end  HEAPSRT; 


Figure  4:  SDVS  Version  of  HEAPSRT  Procedure 
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Figure  4  shows  the  transformed  version  of  the  HEAPSRT  procedure  used  for  SDVS  analysis. 
Two  types  of  transformations  have  been  applied  to  the  original  source  code.  First,  there 
are  the  transformations  required  by  the  choice  of  the  scaffolding  code  generated  to  isolate 
the  procedure.  These  transformations  consist  (1)  of  the  systematic  replacement  of  local 
variables  of  type  RR-RANGE  by  variables  of  the  same  name  but  of  type  integer,  and  (2) 
of  the  replacement  of  the  local  variable  Q  (originally  of  type  REALS)  by  a  variable  Q  of 
type  integer.  As  a  further  consequence  of  these  changes,  the  one  explicit  type  conversion 
in  the  original  fragment  disappears.  Second,  there  are  transformations  to  the  source  code 
designed  to  overcome  limitations  of  the  SDVS  translator.  At  the  time  this  project  was 
started,  SDVS  did  not  support  f  or-loops,  so  the  for-loop  used  for  initialization  in  the 
original  code  was  replaced  by  a  while-loop  (SDVS  11  now  supports  f  or-loops).  For  clarity, 
and  to  match  the  semantics  of  a  for-loop  more  closely,  a  fresh  integer  variable,  K,  is  used 
in  the  initialization  while-loop.  The  original  code  also  contained  GOTOs.  These  were 
replaced  by  the  introduction  of  an  integer  variable  LABEL,  which  assumes  only  the  values 
10,  20,  or  30,  and  of  a  while-loop  containing  what  amounts  to  a  case  statement  for  the  value 
of  the  variable  LABEL.  Each  path  of  the  case  statement  contains  code  originally  jumped  to 
by  one  of  the  GOTOs,  and  changes  in  the  value  of  the  variable  LABEL  determine  (as  the 
GOTOs  did  originally)  which  portion  of  code  is  executed  next.  Both  of  the  transformations 
of  the  second  type  implicitly  require  the  informal  proof  of  a  claim  that  the  transformed 
code  is  equivalent  to  the  original  code  (with  respect  to  the  properties  being  analyzed). 

The  example  used  here  is  a  good  illustration  of  the  problems  that  are  currently  likely  to  arise 
in  isolating  and  transforming  a  code  fragment  for  SDVS  analysis.  It  shows  that  even  the 
isolation  and  encapsulation  of  code  in  a  scaffold  program  is  liable  to  lead  to  compromises  that 
require  arguments  to  support  claims  of  equivalent  semantics  with  respect  to  properties  being 
analyzed.  Even  if  all  Ada  language  constructs  were  handled  by  SDVS,  such  compromises 
would  tend  to  arise  from  attempting  to  “narrow  the  interface”  by  retaining  only  truly 
relevant  portions  of  the  production  code  matrix  containing  the  fragment.  As  the  example 
shows,  choices  made  in  creating  the  scaffold  code  can  propagate  into  transformations  of  the 
original  fragment  source  code.  The  transformations  of  the  second  kind,  those  required  to 
remold  the  fragment  code  in  terms  of  Ada  language  constructs  handled  by  SDVS,  are  more 
of  a  practical  than  a  theoretical  issue.  From  a  practical  (more  specifically  public  relations) 
point  of  view,  they  are,  however,  quite  significant.  A  customer  whose  code  is  being  verified 
would  surely  like  to  see  the  source  code,  character  for  character,  being  used  as  input  to  the 
analysis.  Not  only  is  this  desirable,  but  the  claims  of  equivalence  that  must  be  made  for 
transformed  code  cloud  the  issue  of  the  extent  to  which  the  code  is  being  (automatically, 
mechanically,  logically,  mathematically  -  pick  your  poison)  verified. 

It  should  be  noted  that  problems  have  a  positive  aspect  as  weU.  Any  individual  problem 
encountered  in  isolating  and  transforming  a  code  fragment  is  likely  to  be  one  that  can  be 
easily  remedied  by  a  plausible  enhancement  to  SDVS,  and  therefore  suggests  the  possibility 
of  such  an  enhancement.  Furthermore,  examples,  such  as  the  heapsort  used  here,  help 
prioritize  tasks  for  future  development  of  the  SDVS  theory  and  tool. 
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4  Analysis  Using  SDVS 


This  section  describes  how  SDVS  can  be  used  on  the  isolated  and  transformed  code  to 
analyze  the  original  question  of  interest.  To  recall,  that  question  is  whether  the  use  of  the 
procedure  HEAPSRT  can  lead  to  attempts  to  store  data  in  unsafe  or  nonexistent  locations. 
This  happens  if  an  array-element  assignment  statement  is  executed  and  the  index  of  the 
array  expression  is  out  of  the  range  of  allowable  indices  for  the  array  in  question.  Note 
that  the  applicability  of  an  analysis  to  the  original  code  fragment,  in  its  original  context,  is 
subject  to  the  validity  of  the  informal  arguments  (supporting  isolation  and  transformations) 
described  in  previous  sections. 

In  SDVS  any  array  assignment  statement  must  have  provably-in-range  indices  before  it  can 
be  symbolically  executed.  Thus  any  proof  of  termination  of  a  program  guarantees  that  the 
memory  corruption  problem  cannot  occur.  A  look  at  the  SDVS  version  of  the  code  shows 
two  different  varieties  of  array  assignment  statements  -  those  in  the  outer  scope  and  those 
occurring  within  procedure  HEAPSRT.  For  the  outer  scope  statements,  termination  shows 
only  that  the  particular  scaffold  chosen  will  be  safe,  and  carries  no  guarantee  of  general 
applicability.  However,  the  proof  will  be  by  means  of  a  lemma  concerning  the  procedure 
HEAPSRT  -  one  that  establishes  that  HEAPSRT  returns  (in  lOUT)  an  array  of  in-range 
indices.  The  meaning  of  this  lemma  is  that,  regardless  of  context,  an  assignment  statement 
will  execute  safely  if  the  index  is  of  the  form  lOUT(J),  where  J  is  an  in-range  index  and 
lOUT  denotes  the  array  returned  by  HEAPSRT.  For  the  second  variety  of  array  assignment 
statements,  those  that  occur  within  the  body  of  HEAPSRT,  the  proof  of  the  lemma  will 
establish  safety  for  all  calls  to  HEAPSRT  that  satisfy  the  preconditions  of  the  lemma, 
because  that  proof  requires  the  symbolic  execution  of  HEAPSRT. 

Below  is  the  lemma  in  question,  expressed  in  the  form  of  a  createadalemma  command. 
(Definitions,  proofs,  commands,  and  the  like  are  shown  in  the  compact  form  produced  by  a 
write  command  in  SDVS,  rather  than  as  they  would  be  typed  at  the  terminal.  Lower  case 
is  used  for  readability,  taking  advantage  of  the  case  insensitivity  of  Ada  identifiers.) 

createadalemma  heapsrt . returns . indices 

file:  \"/u/campbell/ada/heapsrtf iles/sdvs_heapsrt .a\" 
procedure:  heapsrt 

qualified  name:  sdvs_heapsrt. heapsrt 

precondition:  (.n  ge  l,.n  le  range(iout)) 
mod  list:  (iout) 

postcondition :  (f ormula(iout . indexes . slice) ) 

The  precondition  states  that  the  input  argument  N  to  HEAPSRT  must  satisfy  1  <  N  < 
range(IOUT),  and  the  postcondition  is  defined  by 

(def formula  iout . indexes . slice 

"forall  u  (1  le  u  &  u  le  #n  — >  1  le  #iout[u]  &  #iout[u]  le  #n)") 

which  expresses  the  property  that  each  index  value  lOUT(u)  is  in  the  range  1..N,  for  each 
u  in  that  range. 
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The  proof  of  termination  of  the  main  program,  assuming  the  truth  of  the  lemma,  is  captured 
in  the  following  goal  definition  and  proof  scheme 

(defsd  sdvs.heapsrt. terminates. sd 
"[sd  pre:  (ada(sdvs_heapsrt.a)) 
comod:  (all) 
mod:  (all) 

post:  (terminated(sdvs_heapsrt))] ") 

( def proof  proof . mod . adalemma 

" (prove  sdvs_heapsrt .terminates . sd 
proof : 

(go  #sdvs_heapsrt\\pc  =  at (sdvs.heapsrt .heapsrt) , 
invoke adalemma  heapsrt .returns . indices , 
go  #iout  =  #z, 

provebygeneralization  forall  v  (1  le  v  &  v  le  6 

— >  1  le  .z[v]  ft  .zCv]  le  6) 

using:  (q(l)), 

go. 

proveby inst ant iat ion  f ormul a (z . k . in . bounds ) 
using:  q(l) 

substitutions :  (v= .k) , 

go. 

proveby  inst  suit  iat  ion  f  ormul  a  (z .  k .  in .  boimds ) 
using:  q(l) 

substitutions:  (v=.k), 

go. 

provebyinstantiation  formula(z.k. in. bounds) 
using:  q(l) 

substitutions :  (v=.k) , 

go. 

provebyinstantiation  formula(z.k. in. bounds) 
using:  q(l) 

substitutions :  (v=.k) , 

go. 

provebyinstantiation  formula(z.k. in. bounds) 
using:  q(l) 
substitutions :  (v= .k) , 

go. 

provebyinstantiation  f ormula(z .k. in.bo\mds) 
using:  q(l) 

substitutions:  (v=.k), 
go))") 

The  proof  has  a  simple  pattern.  Symbolic  execution  of  the  program  proceeds  automatically 
to  the  point  where  the  main  program  makes  its  single  caU  to  the  procedure  HEAPSRT.  At 
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that  point  the  lemma  is  invoked,  and  symbolic  execution  leads  to  the  point  at  which  the 
procedure  is  exited  and  the  postcondition  f  ormulaCiout .  indexes .  slice)  is  true.  The  next 
command  proceeds  to  the  point  at  which  the  output  formal  argument  (lOUT)  is  identified 
with  the  actual  argument  (Z)  in  the  call.  At  this  point  the  postcondition,  which  was  a 
property  of  lOUT  is  transferred  to  Z  (by  means  of  a  provebygeneralization  command 
and  the  equality  of  Z  and  lOUT),  and  becomes  a  property  of  the  actual  argument  Z.  The 
proof  then  proceeds  automatically,  by  symbolic  execution,  to  the  first  iteration  of  the  loop 
for  displaying  the  sorted  output,  where  the  “put(X(Z(K)))”  statement  is  encountered.  At 
this  point  a  prood  is  required  that  the  symbolic  array  index  Z(K)  is  within  bounds,  before 
the  “put”  statement  can  be  executed.  The  formula  proved  on  exit  from  HEAPSRT 

forall  V  (1  le  V  4  V  le  6  — >  1  le  .z[v]  4  .z[v]  le  6) 

which  is  known  as  q(l)  at  this  point  in  the  proof,  is  used  to  establish  the  required  property, 
namely  formulaCz.k. in.boimds),  defined  as 

(def formula  z .  k .  in .  boimds 

".z[.k]  ge  origin(x)  4  .z[.k]  le  (origin(x)  +  range(x))  -  1") 

The  same  pattern  is  followed  for  the  remaining  five  iterations  of  the  loop  body,  and  then 
the  program  proceeds  automatically  to  termination.  There  are  more  elegant  ways  of  sym¬ 
bolically  executing  through  the  output  loop  than  by  reproving  the  same  result  six  times, 
but  this  way  works  and  requires  no  additional  lemmas.  Note  that  the  proof  is  very  short, 
meaning  that  SDVS  did  most  of  the  work  in  carrying  the  symbolic  execution  to  its  conclu¬ 
sion.  The  form  in  which  the  proof  was  captured  (i.e.,  a  list  of  proof  commands)  omits  a 
great  deal  of  detail  that  would  be  seen  in  a  full  proof  trace. 

What  has  been  proved  is,  of  course,  only  that  the  main  program  terminates  if  one  assumes 
the  truth  of  the  adalemma.  It  is  the  proof  of  the  adalemma  that  deals  with  the  intricacies  of 
the  code  in  procedure  HEAPSRT.  The  proof  of  the  adalemma  is  considerably  lengthier  than 
the  above  termination  proof.  As  far  the  issues  of  interest  here  (isolating  and  transforming 
a  code  fragment  for  SDVS  analysis)  are  concerned,  the  actual  proof  of  the  adalemma  is 
virtually  a  technical  detail.  However,  it  turns  out  that  carrying  out  that  proof  revealed  a 
bug  in  the  original  HEAPSRT  code.  This  is  addressed  in  the  next  section,  and  the  actual 
proof  of  the  adalemma  is  given  in  Appendix  A. 

The  following  points  are  worth  making  in  considering  the  relative  roles  of  the  termination 
proof  and  the  proof  of  the  adalemma. 

•  The  adalemma  is  the  central  result  of  the  analysis,  since  it  provides  a  tool  that  can 
be  carried  over  to  the  analysis  of  any  program  that  invokes  procedure  HEAPSRT  (so 
that  the  preconditions  of  the  adalemma  are  satisfied,  of  course). 

•  Once  the  adalemma  has  been  properly  defined  (pre-  and  postconditions,  mod-  and 
comodlists),  its  proof,  while  lengthy,  is  largely  a  matter  of  applying  the  SDVS  mech¬ 
anisms,  and  does  not  raise  any  further  questions  about  claims  concerning  semantic 
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equivalence  or  the  validity  of  transformations.  Rather,  the  proof  pertains  strictly  to 
the  piece  of  code  as  given. 

•  The  selection  of  the  pre-  and  postconditions  for  the  adalemma  is  largely  a  function  of 
what  is  required  for  the  adalemma  to  function  in  the  program  termination  proof. 

•  Even  though  the  scaffold  represents  one  very  particular  instance  of  the  use  of  proce¬ 
dure  HEAPSRT,  the  termination  proof  provides  confidence  that  the  adalemma  is  the 
appropriate  tool  for  proving  the  safety  of  the  use  of  procedure  HEAPSRT  in  other 
contexts  (that  is,  within  other  main  programs).  It  illustrates  that  the  adalemma  is 
actually  a  functional  tool  for  proving  termination.  One  would  not  have  the  same 
confidence  if,  say,  the  scaffold  just  encapsulated  HEAPSRT  without  invoking  it. 

•  The  adalemma  only  establishes  that  HEAPSRT  does  indeed  return  indices  within 
range.  It  does  not  establish  that  the  indices  serve  to  sort  the  values  in  HEAPSRT. 
Thus  if  the  goal  of  the  analysis  were  to  prove  that  HEAPSRT  sorts  correctly,  a  cor¬ 
respondingly  more  complex  adalemma  would  have  to  be  proved.  Such  proofs  have 
already  been  carried  out  in  SDVS  for  implementations  of  certain  other  sorting  algo¬ 
rithms,  e.g.  quicksort  [7]. 
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5  The  Critical  Lemma 


This  section  outlines  the  proof  of  the  adalemma  heapsrt .returns .indices.  The  adalemma 
can  be  stated  informally  as  follows:  if  procedure  HEAPSRT  is  called  with  arguments  N,  X 
and  lOUT,  and  N  is  positive  and  less  than  or  equal  to  the  length  of  the  array  lOUT,  then, 
on  exit  from  HEAPSRT,  N  and  X  are  unchanged  and  each  lOUT(I)  for  1  <  I  <  N  is  an 
integer  in  the  same  range  (1  <  lOUT(I)  <  N).  Note  that  the  adalemma  carries  with  it  the 
obligation  to  prove  that  procedure  HEAPSRT  terminates. 

The  following  is  an  informal  proof  of  termination.  Refer  to  Figure  4  for  the  complete  text 
of  the  SDVS  version  of  the  HEAPSRT  procedure.  The  code  has  the  following  structure: 


declarations 

begin 

Bhile-/oop  to  initialize  lOUT(k)  to  k,  for  k  in  1..N 

L: =1/2+1; 

IR:=I; 

LIBEL  :=  10; 

Bhile  LABEL  /=  30  loop 
ir  LABEL  =  10  then 

code  block  to  execute  if  LABEL  is  1 0 

elsif  LABEL  =  20  then 

code  block  to  execute  if  LABEL  is  20 

end  if;  —  "case"  statement  on  LABEL  values 
end  loop;  —  uhile  LABEL  /=  30 
end  HEAPSRT; 


Figure  5:  Outline  of  HEAPSRT  Procedure 

The  vhile-loop  that  initializes  lOUT  terminates.  Then  the  while-loop  on  LABEL  is  en¬ 
tered,  with  LABEL  equal  to  10.  The  code  block  executed  when  LABEL  is  10,  namely 

if  L>1  then 
L:=L-1; 

IOnTT:=IOOT(L); 

Q:=I(I0UTT); 

else 

I0UTT:=I0UT(IR); 

Q:=I(I0OTT); 

I0UT(IR):=I0OT(l); 

IR:=IR-1; 
if  IR=1  then 

10nT{l):=I0OTT; 

LABEL  :=  30; 
end  if; 
end  if; 

if  LABEL  /=  30  then 
I:=L; 

J:=L+L; 

LABEL  :=  20; 
end  if; 
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decrements  the  quantity  L+IR  by  exactly  one.  Neither  L  nor  IR  is  changed  in  the  code 
block  executed  when  LABEL  is  20,  namely 

if  J<=IR  then 
if  J<IR  then 

if  I(I0UT(J))<X(I0UT(J+1))  then 

end  if; 
end  if; 

if  q<Z(I0UT(J))  then 
IQUTd)  :=iaUT(J) ; 

I:=J; 

J:=J+J; 

else 

J:=1R+1; 
end  if; 

else 

I0OT(I):=10OTT; 

LiBEL  :=  10; 
end  if; 


If  one  assumes  that  both  L  and  IR  should  be  positive  at  all  times  (since  they  are  used  as 
indices),  then  it  is  clear  that  the  first  block  can  be  executed  at  most  finitely  many  times. 
Whenever  the  first  block  is  exited,  there  are  three  possible  values  for  LABEL:  10,  20,  30. 
If  LABEL  is  30,  termination  occurs;  if  LABEL  is  10,  we  get  another  execution  of  the  first 
block.  Finally,  if  LABEL  is  20,  we  execute  the  second  block.  Execution  remains  within 
the  second  block  until  J  >  IR,  at  which  point  control  passes  back  to  the  first  block.  Thus 
it  remains  to  show  that  the  second  block  can  be  repeatedly  executed  in  succession  only 
a  bounded  number  of  times.  But  each  successive  execution  of  the  second  block  with  J 
<  IR  increases  the  value  of  J  without  changing  IR.  This  completes  the  informal  proof  of 
termination. 

Of  course,  termination  is  not  the  only  thing  to  be  proved.  One  must  also  verify  that  the 
desired  conclusion  (that  the  values  of  lOUT  are  proper  indices)  holds.  Consider  the  formula 

forall  u  (1  le  u  &  u  le  .n  — >  1  le  .iout[u]  &  .iout[u]  le  .n) 

It  holds  once  lOUT  has  been  initialized,  so  if  it  can  be  shown  that  it  continues  to  hold 
during  the  execution  of  the  while-loops  on  LABEL,  it  will  hold  when  execution  of  procedure 
HEAPSRT  terminates  (at  procedure  exit). 

The  SDVS  proof  of  adalemma  heapsrt.returns.indices  was  set  up  along  the  lines  suggested 
by  the  above.  That  is,  in  outline,  the  proof  consists  of  an  induction  to  establish  that  lOUT 
has  been  initialized,  symbolic  execution  to  the  point  just  before  the  while-loop  on  LABEL, 
and  then  two  nested  inductions,  one  on  L-FIR  and  one  on  IR-J.  For  technical  reasons  the 
proof  is  actually  more  complicated  than  this;  e.g.  the  induction  on  IR-J  is  repeated  to 
deal  with  two  different  cases  in  the  L-I-IR  induction,  and  additional  stretches  of  symbolic 
execution  (without  induction)  must  be  added  to  the  proof  to  deal  with  boundary  cases. 

The  proof  is  fairly  long,  partly  because  there  are  many  different  paths  for  possible  symbohc 
execution  through  the  code,  due  to  the  large  number  of  conditionals.  One  of  these  paths 
led  to  the  discovery  of  a  bug  in  the  HEAPSRT.  The  bug,  and  a  fix,  are  described  in  the 
next  section.  The  proof  of  the  adalemma  (for  the  corrected  code)  is  listed  in  Appendix  A. 
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6  Discovering  a  Bug 


What  actually  happened  when  the  proof  of  adalemma  rudheap. returns. indices  was  at¬ 
tempted  was  that  a  previously  unnoticed  hug  in  HEAPSRT  surfaced.  It  was  unnoticed 
precisely  because  it  was  on  the  path  of  a  symbolic  execution  that  would  not  tend  to  be 
encountered  in  practice.  Consider  the  block  of  code  executed  when  LABEL  is  10,  and, 
more  exactly,  the  statements 

IR:=IR-1; 
if  IR=1  then 

lOUT(l) :=iaUTT; 

LABEL  :=  30; 
end  if; 


If  procedure  HEAPSRT  is  called  with  N  >  2,  then  the  initial  value  of  IR  is  2  or  more, 
and  the  statements  will  (eventually)  cause  IR  to  be  decremented  to  1,  LABEL  will  be  set 
to  30,  and  the  while-loop  on  LABEL  wiU  terminate  in  short  order.  On  the  other  hand,  if 
HEAPSRT  is  called  with  N=l,  these  statements  wiU  be  reached  almost  immediately,  IR  will 
be  decremented  from  1  to  0,  and  LABEL  will  not  be  set  to  30.  Inspection  of  the  code  shows 
that  if  out-of-bounds  array  indices  are  not  detected,  the  result  will  be  an  infinite  loop  (the 
second  block,  where  LABEL  is  20,  sets  lOUT(l)  to  lOUTT  and  then  resets  LABEL  to  10). 
That  infinite  loop  wiU  also  then  copy  values  into  the  locations  lOUT(O),  lOUT(-l),  and  so 
on,  thus  overwriting  supposedly  safe  memory  locations.  If  out-of-bounds  array  accesses  are 
detected,  then  the  second  execution  of  the  block  of  code  for  LABEL  equal  to  10  wiU  result 
in  detecting  the  erroneous  access  lOUT(O). 

This  is  definitely  a  bug,  even  though  attempting  to  sort  arrays  of  length  1  is  not  a  frequent 
occurrence.  It  is  also  obvious  that  the  bug  was  in  the  original  Fortran  code,  and  had  nothing 
to  do  with  either  the  translation  into  Ada  or  the  isolation/transformation  of  the  procedure. 
When  the  bug  was  found,  an  appropriate  test  case  was  set  up,  and  the  execution  of  the  Ada 
main  program  was  abandoned  when  a  constraint  error  was  raised  (because  RR_RANGE 
was  declared  to  be  a  derived  type  of  POSITIVE).  Thus  the  bug  could  have  (should  have?) 
been  caught  if  there  had  been  just  a  little  more  sophisticated  testing  of  the  executable  Ada 
version. 

Here  is  the  patch  that  was  made  to  the  code  to  correct  the  bug.  The  statements  above  were 
replaced  by 


if  IR>2  then 
IR:=IR-1; 

else 

lOUT(l) :=I0UTT; 
LABEL  :=  30; 
end  if; 


The  reason  that  the  attempted  proof  led  to  the  discovery  of  the  bug  was  that  one  of  the 
induction  invariants  was  IR  >  0,  and  this  could  not  be  proved  with  the  flawed  code.  With 
the  above  flx  in  place  the  proof  was  successfully  carried  out.  It  is  listed  in  Appendix  A. 
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7  Conclusions 


The  discussion  in  the  previous  sections  is  designed  to  highlight  the  following  aspects  of  the 
isolation,  transformation,  and  analysis  of  code  fragments  from  larger  programs  (production 
codes). 

1.  Compromises  of  the  semantics  of  production  code  are  virtually  inevitable  when  a  code 
fragment  is  isolated  from  a  larger  matrix. 

2.  Source  code  transformations  are  currently  almost  inevitable  when  the  code  fragment 
is  adapted  for  SDVS  analysis. 

3.  Both  items  1  and  2,  above,  impact  the  formal  nature  of  verification. 

4.  Informal  arguments  are  necessary  to  support  analysis  of  code  fragments. 

5.  Scaffold  code  is  a  distinct  help  in  analyzing  a  code  fragment. 

The  last  point  mentioned  concerns  the  fact  that  although  the  scaffold  code  is  often  theo¬ 
retically  irrelevant  to  the  goal  of  the  analysis,  it  provides  significant  support  in  analyzing 
a  program  fragment:  feedback  from  compilation,  execution,  and  interactive  proofs  in  a 
realistic  setting. 

The  fact  that  a  bug  was  found  in  the  HEAPSRT  procedure  chosen  for  analysis  illustrates 
one  of  the  benefits  of  formal  verification.  The  bug  really  had  nothing  to  do  with  either  the 
isolation  of  the  code  fragment  or  the  transformations  applied  to  it.  The  points  above  would 
be  equally  valid  if  the  code  had  been  free  of  bugs. 

Finally,  the  following  are  some  recommendations  for  near-term  changes  to  SDVS  that  would 
have  been  helpful  in  this  exercise: 

1.  Allow  for  subtypes  and  derived  types.  Even  if  implemented  only  for  the  base-type 
integer,  this  would  (a)  allow  for  the  more  convenient  naming  of  index  types,  and  (b) 
permit  greater  fidelity  to  the  original  source  code  by  providing  arbitrary  character 
strings  as  type  names  (for  the  subtypes  or  derived  types). 

2.  Identify  formal  and  actual  parameters  more  closely.  Currently,  properties  of  scalar 
formal  parameters  to  a  procedure  carry  over  to  actual  parameters  of  output  type  [2]. 
In  the  proof  of  termination  for  HEAPSRT,  it  was  explicitly  necessary  to  transfer  a 
property  of  the  formal  parameter  lOUT  to  the  actual  output  parameter  Z,  because 
the  parameters  were  arrays.  It  would  be  useful  if  the  transfer  were  automatic  for 
arrays  as  well. 
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A.  Proof  of  the  adalemma  heapsrt.returns.indices 


This  appendix  provides  a  listing  of  the  proof  of  the  adalemma  heapsrt.returns.indices  and 
some  supporting  materials.  To  avoid  any  possible  confusion,  the  first  item  is  a  listing  of  the 
(bug-fixed)  version  of  procedure  HEAPSRT  to  which  the  lemma  applies. 

procedure  HEAPSRT  (■  :  in  integer; 

X  :  in  X_RR_iRRAY  ; 

IQUT  :  in  ont  RR.IIDEX.ARRAY)  is 
I.L.IR, J.IOUTT;  integer;  Q:  integer; 

K, LABEL:  integer; 

Begin 

K  :=  1; 

shile  K  <s  I  loop 
I0UT(K):=K; 

K  :=  X  +  1; 
end  loop; 

L: =1/2+1; 

IR:=I; 

LABEL  :=  10; 

Bhile  LABEL  /=  30  loop 
if  LABEL  =  10  then 
if  L>1  then 
L:=L-1; 

IOUTT:=IOOT(L); 

q:=X(I0UTT); 

else 

IOUTT:=IOOT(IR); 

q:=x(iourr); 

lOUT(IR) :=I0UT(1) ; 
if  IR>2  then 
IR:=IR-1; 

else 

lOUT(l) :=I0UTT; 

LABEL  :=  30; 
end  if; 
end  if; 

if  LABEL  /=  30  then 
I:=L; 

J:=L+L; 

LABEL  :=  20; 
end  if; 

elsif  LABEL  =  20  then 
if  J<=IR  then 
if  KIR  then 

if  X(IOUT(J))<X(IOOT(J+1))  then 
J:=J+1; 
end  if; 
end  if; 

if  q<X(I0UT(J))  then 
I0UT(I):=I0UT(J); 

I:=J; 

J:=J+J; 

else 

J:=IR+1; 
end  if; 

else 

IOOT(I):=IODTT; 

LABEL  :=  10; 
end  if; 

end  if;  —  "case"  statement  on  LABEL  values 
end  loop;  —  shile  LABEL  /=  30 
end  HEAPSRT; 


Next,  here  are  a  variety  of  dehnitions  of  items  that  appear  in  the  proof  of  the  adalemma. 

(deffoianla  iont . indexes .slice 

''foxall  n  (1  le  n  t  u  le  tn  -->  1  le  tiontCn]  ft  tiont[u]  le  tn)"} 

(defformla  iont .in. range 

"forall  n  (1  le  n  ft  n  le  .n  — >  1  le  .iont[n3  ft  .iontCn]  le  .n)“) 

(defsd  dxopi.sd 

"Csd  pre:  (1  le  .n  ft  .n  le  range (iont) ,1  le  .i  ft  .i  le  .n, 
forall  n  ((1  le  n  ft  n  le  .n)  ft  n  .i 

1  le  .iontCnl  ft  .iontCn]  le  .n), 

1  le  .iontC.i]  ft  .iontC.i]  le  .n) 

post:  (fora]  1  n  (1  le  n  ft  n  le  .n  — >  1  le  .ionttnl  ft  .ioat[n]  le  .n))]") 

(defsd  dis joint. sd 
"[sd  pre;  (tme) 

post:  (alldisjoint(ioatCl:(.i  +  (-l>)3,iont[.i; .i]) , 
alldisjoint(iontC(.i  t  1) :  .n] .iontt.i: .i]))]"} 

(deffonaola  shile .  invariant 

“forall  n  (1  le  n  ft  n  le  .n  — >  1  le  .iont[n]  ft  .iont[u]  le  .n)  ft 
(1  le  .1  ft  .1  le  .n)  ft 
(1  le  .ir  ft  .ir  le  .n}'*) 

(defsd  initial. values. in. range. sd 

"[ad  pro:  (forall  n  (1  le  n  ft  n  le  .n  — >  .iont[n]  =  u)) 
coood:  (all) 

post:  (forall  n  (1  le  n  ft  n  le  .n  -->  1  le  .iont[n]  ft  .iout[n]  le  .n))]”) 

(defsd  stays.tme.sd 
"[sd  pro:  (tme) 

comod:  (heapsrt .k.iontCl ; ( .heapsrt .k  -  1)]) 

Bod;  () 

post:  (forall  n  (1  le  n  ft  n  It  .heapsrt.k  -->  .iont[n]  =  n))]") 

(defsd  bridge. sd 

"[sd  pre;  (.n  ge  1, forall  n  (1  le  n  ft  n  le  .n 

— >  1  le  .iontCn]  ft  .iontCnj  le  .n)) 

coBod ;  (n) 

Bod:  () 

post;  ([sd  pre:  (tme) 

coBod:  (i,n,iont  [1;  ( .i-D]  ,iont[(  .i+1)  :  .n]) 
post:  (forall  n  ((1  le  n  ft  a  le  .n)  ft  n  '=  .i 

— >  1  le  .iont[n3  ft  .iont[ii]  le  .n) )])]") 

(defsd  bridger.sd 

"[sd  pre:  (.n  ge  1, forall  n  (1  le  n  ft  n  le  .n 

— >  1  le  .iont[n]  ft  .iont[n]  le  .n)) 

coBod :  (n) 

Bod :  ( ) 

post:  ([sd  pro:  (tme) 

comod:  (ir ,n,iout [1 : (.ir-l)J ,iont[(.ir+l) : .n]) 
post:  (forall  n  ((1  le  n  ft  n  le  .n)  ft  n  ~=  .ir 

— >  1  le  .ioiit[n]  ft  .iont['n3  le  .n))])]") 

(defsd  bridgel.sd 

"[sd  pre:  (.n  ge  1, forall  n  (1  le  n  ft  n  le  .n 

">  1  le  .  iont  [nj  ft  .  iont  [n]  le  .  n) ) 

comod :  (n) 
mod:  () 

post:  ([sd  pre:  (true) 

comod :  (n, iont [2 : .n] ) 

post:  (forall  n  ((1  le  n  ft  n  le  .n)  ft  n  "=  1 

— >  1  le  .iont[n3  ft  .iont[n]  le  .n))])]") 
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(defsd  seaken.ix.sd 
"[sd  pre:  (true) 

comod:  (ir,n,iout[l: ( .ir-1)] ,iotit[(.ir+l) ; .n]) 
mod:  (} 

post:  (forall  n  ((1  le  n  t  a  la  .n)  k  n  '=  .ir 

— >  1  la  .iont[a]  t  .iontCn]  le  .n))]") 

(deff ormnlas  induct .lix . inTariants 
•M  ga  1" 

".ir  ga  1" 

•M  la  .n" 

".ir  la  .n" 

".1  +  .ir  =  lir" 

"formlaClabSO)" 

"f  ormalaCiLotSO}  " 

".labal  =  10" 

"formuladout  .in. range)"} 

(deff ormnlas  induct . gap .  invariants 
".ir  -  .j  le  gap" 

".label  =  20" 

"foiinula(lab20)“ 

"f  oxiirala(not20)  " 

"1  le  .i" 

".i  le  .n" 

"1  le  .j" 

"forall  u  (1  le  u  fe  u  le  .n  — >  1  le  .iout[u]  t  .iout[u]  le  .n)") 

Finally,  here  is  the  proof  itself,  in  the  form  of  a  proof  scheme  produced  by  an  SDVS  write 
command.  Two  slight  liberties  have  been  taken  with  the  format:  in  “using:”  clauses  and 
in  provebygeneralization  commands,  the  term  formulaCiout. in. range)  has  been  used 
in  this  listing  instead  of  the  actual  quantified  formula  itself.  It  is  expected  that  this  wiU  be 
acceptable  input  to  SDVS  in  the  near  future. 

(defproof  proof  .of  .adalema 

"(adatr  \"/u/ca]ipbell/ada/heapsrtfiles/sdvs_}ieapsrt  .a\", 
read  \"/u/campbell/ada/heapsrtf iles/defns\", 
createadaleima  heapsrt .returns . indices 

file :  \"/u/ caiqibell/ada/heapsrtf lies/ sdvs_heapsrt . a\" 
procedure:  heapsrt 
qualified  name :  sdvs.heapsrt .heapsrt 

precondition:  (.n  ge  l,.n  le  range(iout)) 
mod  list :  (iout) 

postcondition:  (formulaCiout . indexes .slice}} , 
proveadalemma  heapsrt . returns . indices 
proof : 

(go  Sheapsrt.k  =  1, 
letsd  ul  =  u(i} , 
letsd  u2  =  u(2} , 
let  nn  =  .n, 

induct  on:  .heapsrt .k 

from:  1 

to:  nn  +  1 

invariants:  (formulaCul)  ,formula(u2} , 

forall  u  (1  le  u  k  u  It  .heapsrt .k  — >  .iout[u]  =  u} , 

.n  =  nn,  nn  le  rangeCiout}} 
comodlist :  (} 

modlist :  (sdvs_heapsrt\\pc ,heapsrt .k,iout [ .heapsrt .k] } 

base  proof: 
step  proof: 

(let  kl  =  .heapsrt .k, 

provebygeneralization  forall  u  (1  le  u  k  u  It  kl  — >  .iout[u]  =  u} 
using:  (forall  u  (1  le  u  k  u  It  . heapsrt. k  — >  .iout[u]  =  u}}. 
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apply  a(l), 

let  oldiout  =  .ioat, 

proTebjgeneralization  forall  n  (1  le  u  t  n  It  kl  — >  oldiontCii]  =  u) 
using:  (forall  a  (1  le  u  k  n  It  .heapsrt.k  — >  .iout[u]  =  n}), 
readazioBs  \“/n/Tersy8/sdTs/azioms/arrayco ver ings .  axioms\'' , 
proTebyaziom  alldisjointdoutCl :  (.beapsrt.k  -  D]  ,ioiit  [.heapsrt  .k:  .beapsrt  .k]) 
using:  disjoint\\slices, 
proue  stays.tme.sd 
proof :  , 
apply  u(2) , 
apply  u(2), 
apply  u(l) , 

prorebygeneralization  g(3) 

using:  (forall  u  (1  la  u  t  u  It  kl  — >  .iout[u]  -  u))), 
go  tlabel  ■  10, 

proTe  initial. values. in. range. sd 
proof:  provebygeneralization  g(l) 
using:  (q(l)), 

provebygeneralization  forall  u  (1  le  u  t  u  le  .n  — >  .iout[n]  =  u) 
using:  (forall  u  (1  le  u  k  u  It  nn  1  — >  .iont[u]  =  u)), 
apply  initial. values. in. range. sd, 
read  \'‘/u/versys/ sdvs/azioms/div .  azioins\" , 
provebyazioB  .n  /  2  ge  0 
using:  divgeO, 
provebyaziom  .n  gt  .n  /  2 
using:  divlt, 

notice  fonimla(Bhile .  invariant) , 
letsd  lab30  =  u(2) , 
letsd  not30  =  u(3) , 
prove  disjoint  .sd 
proof : 

(provebyazioB  alldisjoint(iout[l:(.i  -  1)] ,iout[.i: .i]) 
using:  disjoint\\slices, 

provebyazioB  alldisjoint(ioutC( .i  +  1) : .n] ,iout[.i: .i]) 
using:  disjoiut\\slices) , 
letsd  disjoint  ^  u(l) , 
prove  bridge. sd 
proof:  prove  g(l) 

proof:  provebygeneralization  g(l) 

using:  (forBmla(iout .in. range) ) , 
letsd  bridge  =  u(l) , 
prove  bridger.sd 
proof:  prove  g(l) 

proof:  provebygeneralization  g(l) 

using:  (forBula(iout .in. range) ) , 
letsd  bridger  =  u(l), 
prove  bridgel.sd 
proof : 

(provebyazioB  alldisjoint(ioutC2: .n] ,iont [1:1]) 
using:  disjoint\\slices, 
prove  g(l) 

proof:  provebygeneralization  g(l) 

using:  (forBnla(iout. in. range)) , 
letsd  bridgel  =  u(l) , 
prove  dropi.sd 

proof:  provebygeneralization  g(i) 
using:  (q(l)), 
letsd  dropi  =  u(l) , 
cases  .1  +  .ir  le  3 
then  proof: 

(apply  notSO, 
apply  u(2) , 
apply  ud), 

provebyazioB  alldisjoint(iout[l:(.ir  -  D]  ,iout[.ir :  .ir]) 
using:  disjoint\\slices, 

provebyaziom  alldisjoint(ioutC( .ir  +  1) : .n] ,iout[.ir; .ir]) 
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using:  disjoint\\slices, 
prove  Beaken.ir .sd 

proof;  provebygeneraliration  g(l) 

using:  (fonaulaCiout .in. range)) , 

apply  u(2), 
apply  u(2) , 

provebyinstantiation  1  le  .iontC.ir]  k  .iout[.iz]  le  .n 
using:  foramladout .in. range) 
substitutions:  (u=.ir). 
notice  1  le  .ioutt  t  .ioutt  le  .n, 
apply  u(l), 

provebyinstantiation  1  le  .iontCl]  k  .ioutCl]  le  .n 
using:  formnla(iout .in. range) 
substitutions;  (u=l), 
apply  u(l), 
apply  u(3) , 

provebygeneralization  f  omulaCiout .  in  .range) 
using:  (q(l)), 
apply  u(l) , 

provebyazioD  alldis joint (iout [2 : .n] ,iout [1:1]) 
using:  disjoint\\slices, 
apply  brldgel, 
apply  u(2) , 
apply  u(2) , 

provebygeneralization  f  onmlaCiout .  in  .range) 
using:  (q(l)), 
apply  7) 
else  proof; 

(induct  on;  lir 

from:  .1  +  .ir 

to:  3 

invariants :  (fonmlasC induct  .lir  .invariants)) 

comodlist:  (n.heapsrt .z) 

modlist ;  (label,l,ir,i, j, ioutt, iout>q,sdvs_heapsrt\\pc) 

base  proof; 
step  proof: 

(apply  u(l) , 
apply  u(2) , 
cases  .1  le  1 
then  proof: 

(apply  u(l) , 

provebyazioD  alldis joint (iout [1 ; (.ir  -  1)] ,iout[.ir: .ir]) 
using:  disjoint\\slices, 

provebyazioB  alldisjoint(iout[( . ir  +  1) : .n] ,iout[.ir: .ir]) 
using;  disjoint\\slices, 
prove  seaken.ir.sd 

proof:  provebygeneralization  g(l) 

using:  (foniiula( iout .  in. range) ) , 

apply  u(2) , 

provebyinstantiation  1  le  .iout[.ir]  ft  .iout[.ir]  le  .n 
using;  forBiula(iout. in. range) 
subst itut ions ;  (u= . ir )  , 
notice  1  le  .ioutt  k  .ioutt  le  .n. 
apply  u(l) , 

provebyinstantiation  1  le  .iout[l]  k  .iout[l]  le  .n 
using:  foramladout. in. range) 
substitutions;  (u=l) , 
apply  u(l) , 
apply  u(3) , 

provebygeneralization  forall  u  (1  le  u  t  u  le  .n  — >  1  le  .iout 

[u]  k  .  iout  [u] 
le  .n) 

using:  (q(l)), 
apply  u(2) , 
apply  u(l) , 
apply  u(2) , 
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apply  n(l), 
apply  nd), 
apply  u(l), 
apply  n(2) , 
apply  nCl) , 
letsd  lab20  =  it(2), 
letsd  not20  ^  nd)  , 
indnct  on :  gap 

Iroa:  -ir  -  .j 

to:  -1 

invazianta :  (formnlas( indnct .gap . invariants) ) 

coaodlist :  (ir,iieapszt  .z,n,l.q,iontt) 

Bodlist :  (i, j ,iont , label, sdvs.heapsrt\\pc) 

base  proof: 
step  proof: 

(apply  n(2), 
apply  n<2), 
cases  .j  It  .ir 
then  proof: 

(apply  n(2), 

provebyinstantiation  1  le  .iont[.j]  k  .iont[.j]  le  .n 
using:  fonmla(iout. in. range) 
substitutions:  (u=.j), 
provebyinstantiation  1  le  .iont 

[.j  +  1]  k  .iont 
[.j  +  1]  le  .n 

using:  formnla( iont. in. range) 
substitutions:  (u=.j  +  1), 
cases  .heapsrt.z[.ioutC. j]] 

It  .heapsrt .zC.iout [. j  +  1]] 
then  proof: 

(apply  u(2) , 
apply  u(l) , 

cases  .q  It  .heapsrt .x[ . iont [ . j]] 
then  proof : 

(apply  u(2), 
apply  disjoint, 
apply  bridge, 
apply  u(2) , 
apply  u(2) , 
apply  dropi, 
apply  ud), 
apply  ud), 
apply  u(2), 
apply  ud)) 
else  proof ; 

cases  .q  It  .heapsrt .z[. iout [. j]j 
then  proof: 
else  proof: 

(apply  u(2) , 
apply  u(l) , 
apply  u(2) , 
apply  u(l))} 

else  proof: 

(apply  u(2) , 

cases  .q  It  .heapsrt .x[. iont [.j]] 
then  proof : 

(apply  u(2) , 
apply  disjoint, 
apply  bridge, 
apply  u(2) , 
apply  u(2) , 
apply  dropi, 
apply  ud) , 
apply  ud) , 
apply  u(2). 
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apply  tt(l)) 
else  proof: 

cases  .q  It  .lieapsrt.x[.iout[. j]] 
then  proof : 
else  proof : 

(apply  a(2) , 
apply  n(l), 
apply  u(2) , 
apply  nd)))} 

else  proof: 

cases  -j  It  -ir 
then  proof: 
else  proof: 

(apply  n(2), 

provebyinstantiatlon  1  le  .iont 

[.j]  *  .iout[.j]  le  -a 

using:  formuladout .  in. range) 
substitutions :  (u= . j ) , 
cases  .q  It  .heapsrt .zC. iont[ . j]] 
then  proof: 

(apply  u(2) , 
apply  disjoint, 
apply  bridge, 
apply  u(2), 
apply  u(2), 
apply  dropi, 
apply  ud), 
apply  ud) , 
apply  u(2), 
apply  ud)) 
else  proof: 

(apply  u(2), 
apply  ud), 
apply  u(2), 
apply  ud)))), 

cosoient  \"first  induction  on  gap  has  closed\", 

apply  u(2) , 

apply  ud) , 

apply  disjoint, 

apply  bridge, 

apply  u(2) , 

apply  u(2) , 

provebygeneralization  forall  u  (1  le  u  h  n  le  .n  — >  1  le  .iont 

[u]  k  .  iont  [n] 
le  .n) 

using;  (qd)), 
apply  ud)) 
else  proof: 

(apply  u(3) , 
apply  ud) , 

provebyinstantiatlon  1  le  .iout[.l]  ft  .iout[.l]  le  .n 
using;  fomuladont. in. range) 
subst itut ions ;  (u= . 1) , 
apply  ud) , 

notice  1  le  .ioutt  ft  .ioutt  le  .n, 
apply  ud) , 
apply  u(2) , 
apply  ud) , 
apply  ud) , 
apply  ud) , 
apply  u(2) , 
apply  ud) , 
letsd  lab20  =  u{2), 
letsd  not20  =  u(l) , 
cases  .ir  It  .j 
then  proof; 


(apply  ii(2) , 
apply  nd), 
apply  disjoint, 
apply  bridge, 
apply  n(2), 
apply  ii(2), 
apply  dropi, 
apply  n(l)) 
else  proof: 

(induct  on;  gap 

from:  .ir  -  .j 

to:  -1 

invariants :  (fonmlas  (indnct  .gap.  invariants) ) 
comodlist :  (ir,heapsrt .z,n,l,q,iontt) 

modlist:  (i,j,iont, label, 

sdvs_beapsrt\\pc) 

base  proof: 
step  proof; 

(apply  n(2), 
apply  n(2), 
cases  .j  It  .ir 
then  proof: 

(apply  0(2), 

provebyinstantiation  1  le  .iont 

[.jj  t  .iont[.j]  le  .n 
using:  formnlaCiont .in. range) 
substitutions :  (u= . j ) , 
provebyinstantiation  1  le  .iout 

[•j  + 

1]  t  .iont 

[.j  +  1] 

le  .n 

using;  formnlaCiout .in. range) 
substitutions:  (u=.j  +  1), 
cases  .heapsrt.zC.ioutC. j]] 

It  . heapsrt . z 

C.ioutC.j  +  1]] 

then  proof; 

(apply  u(2), 
apply  u(l), 

cases  .q  It  .heapsrt.z[.iout[. j]] 
then  proof : 

(apply  u(2) , 
apply  disjoint, 
apply  bridge, 
apply  u(2) , 
apply  u(2) , 
apply  dropi, 
apply  u(l) , 
apply  u(l) , 
apply  u{2) , 
apply  u(l)) 
else  proof ; 

cases  .q  It  . heapsrt. z 

[.iout[.  j]] 

then  proof : 
else  proof ; 

(apply  u(2), 
apply  u(l) , 
apply  u(2) , 
apply  u(l))) 

else  proof : 

(apply  u(2) , 

cases  .q  It  .heapsrt .z[. iout [. j]] 
then  proof : 

(apply  u(2) , 
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apply  disjoint, 
apply  bridge, 
apply  n(2) , 
apply  n(2), 
apply  dropi, 
apply  nd), 
apply  nd), 
apply  n(2) , 
apply  nd)) 
else  proof: 

cases  -q  It  .heapsrt.x 

[.iont[.  j]] 

then  proof: 
else  proof: 

(apply  n(2) , 
apply  nd) , 
apply  n(2) , 
apply  nCl)))) 

else  proof : 

cases  ■}  It  .ir 
then  proof: 
else  proof: 

(apply  n(2), 

provebyinstantiation  1  le  .iont 

[ . j]  k  . iont 

[■j3 

Ic  .n 

nsing:  formnla(iont . in. range) 
snbstitntions:  (n=.j), 
cases  .q  It  .heapsrt .x[. iont [. j]] 
then  proof: 

(apply  n(2), 
apply  disjoint, 
apply  bridge, 
apply  n(2), 
apply  n(2) , 
apply  dropi, 
apply  nd) , 
apply  nd), 
apply  n(2) , 
apply  nd)) 
else  proof : 

(apply  n(2), 
apply  nd) , 
apply  n(2) , 
apply  nd)))) , 

comment  \''second  indnction  on  gap  has  closed\", 

apply  n(2) , 

apply  nd) , 

apply  disjoint, 

apply  bridge, 

apply  n(2), 

apply  n(2) , 

apply  dropi, 

apply  nd)))), 

apply  nd) , 
apply  n(2) , 
notice  .1  +  .ir  =  3, 
cases  .  1  8*  1 
then  proof : 

(apply  n(2) , 
apply  nd) , 

provebyinstantiation  1  le  .iont[.l]  ft  .iont[.l]  le  .n 
nsing:  formala(iont .in. range) 
snbstitntions :  (n= . 1) , 
apply  nd) , 
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notice  1  le  .iontt  k  .iontt  le  .n, 

apply  nCl), 

apply  ii(2) . 

apply  u(l), 

apply  nCl) , 

apply  ltd) , 

apply  q(2). 

apply  nd) , 

apply  11(2) , 

apply  nCl) , 

apply  disjoint, 

apply  bridge, 

apply  q(2) , 

apply  n(2) , 

provebygeneralizat ion  f onmlaCiont .  in .  range) 
nsing:  (qd)), 
apply  nCl) , 
apply  n(2) . 
apply  n(2) , 
apply  nd) , 

provebyinstantiation  1  le  .iont[.ir]  ft  .iont[.ir!]  le  .n 
using:  fonmlaCiont. in. range) 
substitutions;  (n=.ir), 
apply  uCl) , 

notice  1  le  .ioutt  k  .ioutt  le  .n, 
apply  ud) , 

provebyinstantiation  1  le  .iont[l]  k  .iout[l]  le  .n 
nsing:  fazmnla(iont.in.range) 
substitutions:  (u=l), 

provebyazioD  alldis joint (iont [1 :(. ir  -  1)] .ioutC.ir: .irl) 
using:  disjoint\\slices, 

proTebyazion  alldis joint (ioutCC.ir  *  1) : .n] ,iout[.ir ; .ir]) 
using:  disjoint\\slices, 
apply  bridger, 
apply  u(2) , 
apply  u(3) , 

provebygeneralizat  ion  fomnlaCiout  .in. range) 
using:  (qCD), 
apply  uCl) , 

notice  1  le  .ioutt  t  .ioutt  le  .n, 
provebyazioD  alldisjoint(iout[2; .n] ,iout [1 ;!]) 
using:  disjoint\\slices, 
apply  bridgel, 
apply  u(2) , 
apply  u(2) , 

provebygeneralizat  ion  f  orsmlaCiout .  in  .range) 
using:  (qCl)). 
apply  r) 
else  proof; 

(apply  u(2) , 

provebyinstantiation  1  le  .iout[.ir]  k  .iout[.ir]  le  .n 
using;  formulaCiout .in. range) 
subst itnt ions :  (u= . ir ) , 
apply  uCl), 
apply  uCl), 

provebyinstantiation  1  le  .iout[l]  t  .iout[l]  le  .n 
using;  formulaCiout. in. range) 
substitutions;  (u=l), 

provebyazioD  alldisjoint(iout[l:(.ir  -  1)] ,iout[.ir : .ir]) 
nsing:  disjoiut\\slices, 

provebyazioD  alldis  joint  (ioutd.ir  +  1) :  .n]  ,iout[.ir;  .ir]) 
using:  disjoint\\slices, 
apply  bridger, 
apply  u(2) , 
apply  u(3) , 

provebygeneralizat  ion  formulaCiout  .in. range) 
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using; 
apply  uCl), 

proveliyazimn  alldis joint  (iont  [2 :  .n] ,  iont  [1:1]) 
using:  di8joint\\slices, 
apply  bridgel, 
apply  n(2) , 
apply  ii(2) , 

proTobygeneralization  fonmlaCiont  .in. range) 
using:  (q(l)), 
go))), 

comment  \''adalemma  heapsrt .  returns .  indices  has  been  proTed\'’)“) 


The  proof  was  developed  interactively,  of  course,  and  it  is  entirely  possible  that  it  could  be 
shortened  or  made  more  elegant.  For  instance,  several  notice  commands  that  originally 
served  primarily  as  reminders  have  been  left  in  place. 

The  proof  takes  a  bit  more  than  twenty  minutes  on  the  most  recent  version  (12a)  of  SDVS, 
which  became  available  as  this  report  was  being  completed.  The  following  is  a  display  of  the 
proof  state  directly  after  completing  the  proof.  A  few  date  commands  have  been  inserted 
to  demonstrate  the  statement  about  the  length  of  time  it  takes  to  run  the  proof. 

<<  initial  state  >> 

adatr  /u/campbell/ada/heapsrtfiles/sdvs_heapsrt.a  <7> 
read  /u/campbell/ada/heapsrtf iles/defns  <6> 
createadalenuna  heapsrt . returns . indices  <5> 
date  "11/2/92  10:29:33  Elapsed  time  is  4  seconds."  <4> 
proveadalemma  heapsrt . returns . indices  <3> 

date  "11/2/92  10:52:37  Elapsed  time  is  23  minutes  and  4  seconds."  <2> 
comment:  adalemma  heapsrt. returns. indices  has  been  proved  <1> 

— >  you  are  here  < — 
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